Software for many deeply embedded systems has been designed to execute as independent programs such that each can run by itself on a computer system without the support of an operating system. Such independent programs are relatively simple (e.g., single-threaded), and consume relatively small amounts of resources such as memory (RAM), time and electrical energy. Yet they are functionally sufficient to meet the original requirements of the embedded systems.
As computer systems evolve, new advanced functionalities, such as Internet capabilities, must be introduced into systems. These advanced features are typically more complex than what an independent program can handle, and usually require the support of a modern OS, such as Linux. The combination of the modern OS and the independent program enables a system to provide both original functionalities with the original independent program, as well as to provide those advanced functionalities that cannot be handled by the independent program itself.
One approach for introducing a modern OS into the system is to port the original independent program into the OS, and let the OS run on the embedded system at all times. Such approach works well for most systems, but less so for systems with power consumption constraints (and with compatibility requirements associated with such constraints), especially if the advanced functionalities are only needed occasionally. The original independent program typically consumes much less energy than a full modern OS, which typically uses a larger amount of memory (e.g., RAM) and IO devices. Having an OS running all the time thus poses a problem for energy-conscious systems. Additionally the independent program, not running stand-alone as in the original design, may pose potential backward-compatibility concerns due to different run-time characteristics (including higher power consumption levels, longer response latencies, etc).
One solution to the above problem is to introduce an additional version/copy of the independent program so as to run inside the OS. In this configuration a system maintains two versions of the independent program: one running autonomously, and the other running under the control of the OS. This configuration has two modes of operation: one used most of the time where the system runs the original independent program autonomously; and the other that loads and executes the OS only when there is need for carrying out tasks or applications that are not supported by the original independent program. The shortfalls of this approach are the extra development cost of the new version of the independent program for running within the OS, the maintenance overhead of two copies of the program, and the runtime complexity for maintaining the data consistency of the two copies of the independent program during mode switches.
By way of further background, one embodiment of the invention disclosed herein relates to process migration, which moves a live process (or thread, object) from one computer to another, primarily for load balancing and other system management purposes. There are mainly two approaches to process migration: one based on checkpoint/restart and typically doesn't require OS support, and the other relies on OS mechanisms. The checkpoint/restart based approach typically uses a user-level library to save process state at some well-defined points, and later restore such saved state. This approached is covered extensively by M. Litzkow, M. Livny, and M. Mutka, Condor—A Hunter of Idle Workstations, 8th International Conference on Distributed Computing Systems, 1988; E. Jul, H. Levy, N. Hutchinson, and A. Black, Finegrained Mobility in the Emerald System, ACM Transactions on Computer Systems, 6(1), 1988; A. Baratloo, M. Karaul, Z. Kedem, and P. Wyckoff. Charlotte: Metacomputing on the Web; Future Generation Computer Systems, 1999; and J. Casas, D. L. Clark, R. Konoru, S. W. Otto, R. M. Prouty, and J. Walpole, MPVM: A Migration Transparent Version of PVM Computing Systems, The Journal of the USENIX Association, 8(2), Spring 1995. This approach normally restricts what the process can do when migrating. For example, the process cannot be involved in I/O operations. The OS-level approach uses OS facilities to capture and move the internal state of a process as well as any kernel state related to the process, optionally leaving behind a proxy on the source site to handle any “residual dependencies” (e.g., active network connections). See for example: M. Rozier, V. Abrossimov, F. Armand, M. Gien, M. Guillemont, F. Hermann, and C. Kaiser, Chorus (Overview of the Chorus Distributed Operating System) Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, 1992; A. Tanenbaum, R. van Renesse, H. van Staveren, G. Sharp, S. Mullender, J. Jansen, and G. van Rossum, Experiences with the Amoeba Distributed Operating System, Communications of the ACM, 33(12), 1990; B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers and C. Chambers, Extensibility Safety and Performance in the SPIN Operating System, 15th Symp. On Operating Systems Principles, December 1995; and F. Douglis and J. Ousterhout, Transparent Process Migration: Design Alternatives and the Sprite Implementation, Software-Practice and Experience, 21(8), 1991. Such an approach is applicable to the migration of any general process, but incurs significant run-time overheads in addition to operating system complexity and maintainability costs. The invention herein provides a process that consumes relatively low amounts of resources (including energy).
As will become apparent below, several key differences exist between the inventive system and method herein disclosed and a process migration system as discussed above. First, while the source and destination environments in process migration both involve an operating system, the invention herein concerns the migration of a live, active program between an OS and the hardware environment directly. Second, while process migration is between different processors and requires the recreation of the process image at the destination, the invention herein, does not require that the OS recreate in memory an image of the program migrated in and out of the OS. Lastly, regarding the invention herein, migration decisions are made based on the runtime needs and tradeoffs between conserving energy and supporting new functionalities. This is different from the common purposes of process migration systems.